home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ddn-news / ddn-mgt-bulletin-41.txt < prev    next >
Text File  |  1991-07-10  |  18KB  |  390 lines

  1. ********************************************************************** 
  2. DDN MGT Bulletin 41              DCA DDN Defense Communications System   
  3. 7 Oct 88                         Published by: DDN Network Info Center
  4.                                     (NIC@SRI-NIC.ARPA)  (800) 235-3155
  5.  
  6.  
  7.                         DEFENSE  DATA  NETWORK
  8.  
  9.                          MANAGEMENT  BULLETIN
  10.  
  11. The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
  12. Information Center under DCA contract as a means of communicating
  13. official policy, procedures and other information of concern to
  14. management personnel at DDN facilities.  Back issues may be read
  15. through the TACNEWS server ("@n" command at the TAC) or may be
  16. obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or
  17. 10.0.0.51] using login="anonymous" and password="guest".  The pathname
  18. for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
  19. bulletin number).
  20. **********************************************************************
  21.  
  22.             DEFENSE DATA NETWORK PACKET SWITCH SOFTWARE DEPLOYMENT
  23.  
  24.  
  25.  
  26. MANAGERIAL INFORMATION
  27.  
  28. DCA Msg 281940Z Sep 88
  29.  
  30. Subject:      Defense Data Network Packet Switch Software Deployment
  31.               Managerial Information
  32.  
  33. Reference:    DCA Msg 281941Z Sep 88, Defense Data Network Packet Switch
  34.               Software Deployment, Technical Information
  35.  
  36. 1.  Defense Data Network Packet Switch Software Deployment
  37.  
  38. By this message the Defense Communications Systems Data Systems (DCSDS)
  39.  
  40.     a.   Establishes the plan for deploying the Defense Data Network's Packet
  41.          Switching Node Release 7.0 New End-to-End (DDN PSN 7.0 NEE) system
  42.          to the MILNET (see the deployment schedule in section 2.),
  43.  
  44.     b.   Solicits the cooperation and participation of the MILNET subscriber
  45.          community during the deployment testing which begins 29 October 1988
  46.          (see subscriber testing responsibilities in section 3.),
  47.  
  48.     c.   Requests MILNET subscribers to identify their host's X.25 facilities
  49.          negotiation capabilities by 1 January 1989 (section 4.), and
  50.  
  51.     d.   Provides a brief status of recent activities leading to this stage
  52.          of deployment (section 4.).
  53.  
  54. By the referenced message DCSDS provides a PSN 7.0 technical status based
  55. upon the recent off-line testing with MILNET hosts.
  56.  
  57. The Defense Data Network (DDN) will soon contain a new version of Packet
  58. Switching Node (PSN) software designated PSN 7.0 NEE, which more strictly
  59. complies with the CCITT Recommendation X.25.  The strict adherence to
  60. standards requires a deliberate deployment approach coordinated with
  61. subscribers to ensure continuity of MILNET operations.  Subscribers who do
  62. not participate in the activities preparatory to the final PSN 7.0 NEE
  63. deployment risk loss of MILNET service due to incompatibility.  Consequently,
  64. request all addressees to acknowledge receipt of this message to DCA
  65. WASHINGTON DC //B610//.  (Note: Based upon the ARPANET Beta testing, AHIP
  66. user impact is not acticipated; however, prudent MILNET testing indicates
  67. that AHIP subscribers should also participate.)
  68.  
  69.  
  70. 2.  PSN 7.0 NEE Deployment Approach and Schedule
  71.  
  72. The PSN 7.0 NEE deployment is the second phase of the PSN 7.0 deployment on
  73. MILNET.  (Phase 1 was the MILNET deployment of PSN 7.0 Old End-to-End (OEE),
  74. a PSN 6.0-compatible system, achieved by 30 August 1988.)  The Phase 2
  75. deployment will consist of five interim short duration cutover tests and a 
  76. final permanent cutover.  The interim cutovers will provide ample opportunity
  77. for both subscribers and network analysts to participate in a MILNET 
  78. operational test of PSN 7.0 NEE prior to its permanent operational use.  The 
  79. first three interim cutovers will occur on weekends.  The next two cutovers
  80. will occur on a weekday to maximize the PSN 7.0 NEE system's exposure in the
  81. MILNET.  The final cutover will take place at the begining of the week.  The
  82. cutover schedule follows:
  83.  
  84.     Day       Time
  85.     Cutover   Zulu/Eastern       Zulu   Eastern    Duration
  86.  
  87.     C1        29/29 Oct 88       1600Z  1200 EDT   12 hours
  88.     C2        12/12 Nov 88       1100Z  0600 EST   12 hours
  89.     C3        19/19 Nov 88       1100Z  0600 EST   24 hours
  90.     C4        30/30 Nov 88       0501Z  0001 EST   24 hours
  91.     C5        14/14 Dec 88       0501Z  0001 EST   24 hours
  92.     C6        09/09 Jan 89       0501Z  0001 EST   Permanent
  93.  
  94. The dates are subject to modification as testing proceeds depending on test
  95. results.  The dates also are negotiable for military exigencies.  Additional
  96. tests may be scheduled on an individual host or MILNET-wide basis.  DCSDS
  97. will notify the subscriber community of any schedule modifications.  
  98.  
  99.  
  100. 3.  Procedures and Operational Support for Phase 2 Deployment
  101.  
  102. The first hour of each period in section 2. above will be dedicated to the
  103. cutover of PSN 7.0 from OEE to NEE, a MILNET-wide cutover.  The Cambridge
  104. Monitoring Center (CMC) will cutover groups of PSNs at a time to NEE.  DCSDS
  105. directs subscribers not to attempt communications during this period for two
  106. reasons: the cutover segments the network and taxes network resources.  Thus,
  107. communications will be slow or nonexistent during the hour.
  108.  
  109. The second hour of the test period will mark the beginning of the operational
  110. test.  DCSDS asks subscribers to participate in the test by exercising their
  111. normal applications and reporting anomalies to the Monitoring Center Trouble
  112. Desk in their respective areas (the PMMC, CMMC or EMMC) using established
  113. reporting procedures.  Should the Trouble Desk's telephone be busy, please
  114. call again.  If you can still not reach the Trouble Desk, please report your
  115. problem via electronic mail to MILUPGRADE@BBN.COM, using the format
  116. outlined in the next paragraph.  Additional staff will support the Trouble
  117. Desks during the testing periods.  Also, network analysts located at the CMC
  118. will provide expert assistance.
  119.  
  120. In order to efficiently utilize the Trouble Desks, DCSDS asks those people
  121. reporting problems to give the following information to the operator:
  122.  
  123.  
  124.     a.   Reporter's Name
  125.     b.   Reporter's Telephone Number (both Autovon and Commercial)
  126.     c.   Reporter's Address
  127.     d.   URDB Subscriber/System Name
  128.     e.   IP Address
  129.     f.   Equipment Manufacturer and Model Designator
  130.               (Specify Host, Front End, PADs, etc. as appropriate)
  131.     g.   Software Manufacturer and Product Designator
  132.               (Specify Operating System, Network Protocol (X.25B, X.25S, HDH,
  133.               1822), Upper Level Protocols, Application Packages, etc. as
  134.               appropriate and available)
  135.     h.   Statement of Problem
  136.               Attempted Activity or Function
  137.               Expected Result
  138.               Actual Result
  139.               Impact on User
  140.     i.   Availability for follow-up test during test period, hours of
  141.          availability in Zulu time
  142.     j.   Follow-up test POC if different from reporter
  143.  
  144. DCSDS asks subscribers to assist MC personnel as necessary in duplicating
  145. problems to enable an accurate analyses.  See Section 4.1 for additional
  146. testing procedures.
  147.  
  148. The last hour of the test period will be dedicated to cutting back to PSN 7.0
  149. OEE.  The same caveats apply to this hour as to the first hour: do not
  150. attempt communications, service will be slow or nonexistent.
  151.  
  152. The determination to perform the final cutover will be contingent upon the
  153. alleviation of communications disruptions encountered during the tests.  
  154.  
  155.  
  156. 4.  PSN 7.0 Status
  157.  
  158. 4.1  Testing Incidents
  159.  
  160. The problems already encountered during the off-line testing with MILNET
  161. hosts fall under the categories of administration and X.25 conformance.
  162. Incidents encountered during cutover testing may fill a third category of
  163. non-X.25 errors.
  164.  
  165.  
  166. 4.1.1  Administrative Problems and Information Request
  167.  
  168. The off-line testing with MILNET hosts encountered a problem related to flow
  169. control negotiation causing hosts to clear calls.  The superseded
  170. configuration of flow control negotiation parameters for certain PSN host
  171. ports caused the problem and the particular X.25 implementation of PSN 6.0
  172. and PSN 7.0 OEE masked the problem.  A temporary patch will correct the
  173. problem in PSN 7.0 NEE.  The MC will remove the patch during the initial
  174. operational phase of PSN 7.0 NEE upon identification and execution of the
  175. configuration modifications.  
  176.  
  177. In order to correct the configurations, DCSDS asks all subscribers to forward
  178. by 1 January 1989 responses to the following questions via front channel
  179. message to DCA WASH DC //B612//:
  180.  
  181.     Can your host currently negotiate
  182.  
  183.          a. window size,
  184.          b. packet size,
  185.          c. precedence, and
  186.          d. throughput class?
  187.  
  188.     What are the minimum and maximum logical channel numbers your host
  189.     supports?
  190.  
  191. 4.1.2  X.25 Conformance Problems
  192.  
  193. The off-line testing also uncovered a problem related to self-addressed calls
  194. which caused hosts to clear calls.  In one test case the problem surfaced
  195. during a file transfer test; the implication being that the user need not
  196. explicitly request self-addressing to experience the problem.  
  197.  
  198. DCSDS thus asks all subscribers to exercise as much of their normal
  199. applications or general routines as possible to identify the chance of
  200. service denial after operational cutover to PSN 7.0 NEE.
  201.  
  202. 4.1.3  Non-X.25 Incidents
  203.  
  204. The off-line testing encountered a problem related to packet sequencing.  The
  205. host layer above X.25 (IP) improperly fragmented a message.  The problem
  206. workaround (modifying the packet size) indicates that different host
  207. configurations of X.25 interface characteristics can result in terminated
  208. service.
  209.  
  210. Thus, DCSDS not only asks subscribers to exercise their normal applications,
  211. but also to exercise those applications under their variously configurable
  212. environments.
  213.  
  214. An outstanding problem from the ARPANET Beta tests relates to the HDH
  215. interface.  On a random basis the interface between the BBN packet switch and
  216. an ACC Gateway resets itself.  DCSDS has now staffed the problem analysis
  217. effort.
  218.  
  219.  
  220. 5.0  Points of Contact
  221.  
  222. The point of contact for any administrative issues regarding this message
  223. (such as test schedules or configuration requirements) is Mr. George
  224. Bradshaw, DCA Code B612, AV 364-5306, Commercial (703)285-5306, Bradshaw
  225. @ DDN1.ARPA.  The points of contact for any test procedure questions
  226. are Mr. Mark Whitney (BBN, Commercial (617)873-2874, MWhitney @
  227. BBN.COM) and Mr. Edward Smith (BBN, Commercial (703)848-4838, ESmith
  228. @ BBN.COM).  Address questions related to communications protocols
  229. (X.25, IP, etc.) to Mr. Andrew Malis (BBN, AMalis@BBN.COM) with a
  230. courtesy copy to Bradshaw@DDN1.ARPA.  Address any issues of general
  231. community interest to MILUPGRADE@BBN.COM.
  232.  
  233.  
  234. TECHNICAL INFORMATION
  235.  
  236. DCA Msg 281941Z Sep 88
  237.  
  238. Subject:      Defense Data Network Packet Switch Software Deployment
  239.               Technical Information
  240.  
  241. Reference:    DCA Msg 281940Z Sep 88, Defense Data Network Packet Switch
  242.               Software Deployment, Mangerial Information
  243.  
  244. 1.  Defense Data Network Packet Switch Software Deployment
  245.  
  246. This message discusses, in technical terms, the current status of Defense
  247. Data Network Packet Switching Node Release 7.0 New End-to-End (DDN PSN 7.0
  248. NEE) in parallel with section 4 of reference, which provides a managerial
  249. status overview.  This message also provides technical details concerning the
  250. recent PSN 7.0 NEE off-line testing with MILNET hosts.  
  251.  
  252.  
  253. 2.  PSN 7.0 Definition
  254.  
  255. PSN 7.0 is the newest release of software for the DDN's packet switching
  256. nodes.  PSN 7.0 embodies 1) a PSN 6.0-compatible system designated Old
  257. End-to-End (OEE) to facilitate release deployment and 2) the full capability
  258. system designated New End-to-End (NEE).  
  259.  
  260. NEE consumes up to 50% fewer network resources with X.25 transmissions and
  261. consequently has the potential to improve throughput by a similar percentage
  262. depending upon topological and utilization considerations.  These
  263. improvements come primarily through a redesign of subnetwork transport
  264. services and new functionality for network services.  The transport service
  265. improvements provide: 1) efficient X.25 acknowledgment handling throughout
  266. the network, and 2) flow control for congestion within a single packet
  267. switching node.  The network service functions support 1) four levels of
  268. precedence and 2) pre-emption to guarantee throughput of critical traffic
  269. during periods of high network utilization.
  270.  
  271.  
  272. 3.  PSN 7.0 NEE Testing
  273.  
  274. PSN 7.0 will have undergone five distinct periods of testing prior to
  275. operational use on the MILNET:
  276.  
  277.     early 1987          Development Testing
  278.     late  1987          Beta Testing on ARPANET
  279.     mid   1988          Off-line Testing with MILNET hosts
  280.     mid   1988          Phase 1 (OEE) Deployment on MILNET
  281.     early 1988          Phase 2 (NEE) Deployment on MILNET
  282.  
  283. Following its beta testing, PSN 7.0 received extensive operational exposure
  284. on the ARPANET and has become a stable system.  The recent off-line testing
  285. with MILNET hosts has exposed X.25 problems involving self-addressed calls
  286. and flow control negotiation; both issues are discussed later (PSN 7.0 NEE
  287. tested against systems listed below).  DCSDS has completed the deployment of
  288. PSN 7.0 Old End-to-End (OEE) Phase 1.  The PSN 7.0 NEE Phase 2 deployment
  289. will consist of controlled interim and final cutovers to the full capability
  290. PSN 7.0 system.
  291.  
  292.                    PSN 7.0 NEE Tested with Following Systems
  293.  
  294. AFLC           APDS            CCSO/XPNB       DLA             DSACS
  295. ESD/SCO        IDSS            IMMIS           JACS/J/J        NARDAC
  296. NAVTIS         NCPDS           PASS-SDS        PERDIMMS        SAF/ACES
  297.  
  298.  
  299. 3.1  Host Testing Technical Description
  300.  
  301. Two major problem issues currently exist: 1) the superseded configuration of
  302. flow control negotiation parameters for certain PSN host ports, and 2) the
  303. inability of one communications protocol implementation to handle
  304. self-addressed calls.
  305.  
  306. 3.1.1  Flow Control Negotiation
  307.  
  308. CCITT Recommendation X.25 specifies flow control methods which allow the DCE
  309. to be either an active (initiator) or passive negotiating element, depending
  310. upon the network implementation.  In practice, the PSN configuration
  311. parameters "Window and Packet Size Negotiation Subscription" support this
  312. network dependence.  PSN 6.0 and PSN 7.0 OEE ignore the setting of these
  313. parameters and do not actively participate in negotiations.  PSN 7.0 NEE
  314. participates in negotiation when the parameters are set to "yes", which is
  315. also the default setting for MILNET.  Therefore all MILNET hosts, whether or
  316. not they can participate in flow control negotiation will, under PSN 7.0 NEE,
  317. receive negotiation offerings for window and packet size from the PSN.  If
  318. the parameters were set to "no", PSN 7.0 NEE would not send negotiation
  319. offerings to the host.  The problem is that hosts which cannot negotiate will
  320. clear a connection if the PSN attempts negotiation.
  321.  
  322. The resolution to this problem is to configure the PSN host ports properly.
  323. DCSDS has established a deployment approach to 1) provide, in the short term,
  324. a patch to NEE, temporarily reverting the release to PSN 6.0 compatibility,
  325. and 2) define and execute configuration corrections in the long term.
  326.  
  327. 3.1.2  Self-Addressed Calls
  328.  
  329. CCITT Recommendation X.25 states, in essence for the purposes of this
  330. discussion, that an outgoing and incoming call will exist on different
  331. virtual channels with that difference identified by a unique number called
  332. the logical channel number (LCN).  PSN 6.0 and PSN 7.0 OEE did not conform to
  333. the X.25 standard and assigned the same number to an outgoing and incoming
  334. call which was self-addressed.  PSN 7.0 NEE conforms to the standard.  The
  335. result is that at least one higher level protocol implementation which
  336. apparently was sensitive to this difference has not functioned properly
  337. during the off-line tests under PSN 7.0 NEE.  In this case, an FTP
  338. implementation could not transfer files.  The configuration for this test was
  339. an IBM 4300 with a Series 1 front end.  UCLA ARPANET Control Protocol V1.6
  340. resided in the 4300, EDX V5 resided in the Series 1.
  341.  
  342. Several alternatives exist for resolving this problem.
  343.  
  344. a.  Replace or correct the protocol implementations which do not abide by the
  345.     X.25 standard.
  346.  
  347. b.  Modify the PSN 7.0 NEE software to act like PSN 6.0, bringing it out of
  348.     X.25 conformance.
  349.  
  350. c.  Modify the topological aspect of the file transfer by "teleneting" one's
  351.     self to the file's destination and "pulling" the file to the destination
  352.     rather than "pushing" the file to the destination.
  353.  
  354. The following caveats apply to the alternatives.  Alternative a. places the
  355. onus on host administrators, alternative b. is not in accord with government
  356. policy to follow standards, and alternative c. may cause logistics problems
  357. with userid and password assignment.
  358.  
  359. The PSN 7.0 NEE cutover testing results will determine the expedient
  360. alternative based upon the types and extent of subscriber impact throughout
  361. the network.
  362.  
  363. 3.1.3  Flow Control Implementations
  364.  
  365. The PSN 7.0 NEE off-line testing with MILNET hosts uncovered an anomaly in
  366. one implementation of the DOD Internet Protocol.  The IP incorrectly
  367. fragmented a TCP message causing the TCP connection to clear.  The
  368. fragmentation resulted in two "final" (X.25 Category B) packets for the same
  369. sequence of packets.  In the original test the packet size was 256 octets.
  370. The host transmitted a sequence of packets, the first group of which were
  371. correctly category A packets each 256 octets in length.  The second to last
  372. packet of the sequence was a category B packet by virtue of its 128 octet
  373. length (not a "full" packet).  The last packet of the sequence was also a
  374. category B packet by virtue of its size (seven octets).  One experiment
  375. configured a packet size of 128 bytes and yielded a successful workaround
  376. which resulted in a single category B packet of seven octets.  The system was
  377. a Sperry 5000 with Adax X25/IP/TCP.
  378.  
  379.  
  380. 4.0  Points of Contact
  381.  
  382. The point of contact for any administrative questions is Mr. George Bradshaw,
  383. DCA Code B612, AV 364-5306, Commercial (703)285-5306.  The point of contact
  384. for any test procedure questions is Mr. Mark Whitney (BBN, Commercial
  385. (617)873-2874, MWhitney@BBN.COM).  Address questions related to
  386. X.25 technical issues to Mr. Andrew Malis (BBN, AMalis@BBN.COM)
  387. with a courtesy copy to Bradshaw@DDN1.ARPA.  Address any issues of
  388. general community interest to MILUPGRADE@BBN.COM.
  389.  
  390.